Add support to KustoSchemaTools for generating Azure Data Explorer (Kusto) database managed_identity policy KQL, using user-assigned managed identity (GUID objectId) and a list of AllowedUsages.

Requirements:

• KustoSchemaTools must ONLY generate KQL/config payload; it must not execute against a live Kusto cluster.
• The new feature must be accessible from the .NET API that consumer apps call.
• Configuration contract (Option A - structured):
  • objectId: string (GUID of user-assigned managed identity)
  • allowedUsages: string[] (must support AutomatedFlows, ExternalTable, NativeIngestion)
  • The target database name is provided separately (already in existing inputs); do not require database name inside the managed-identity settings object.
• Generated KQL must follow this form (spacing/quoting can match existing formatting conventions in the repo):
  .alter-merge database policy managed_identity [
  { "ObjectId": "", "AllowedUsages": "AutomatedFlows,ExternalTable,NativeIngestion" }
  ]
• Decide whether to support alter vs alter-merge; prefer alter-merge to avoid destroying other policy entries, unless the repo has a strong existing convention.
• Wire the generator into the existing structured diff output model so that the managed identity policy KQL appears in the structured response for a given database.
• Add unit tests that verify the exact generated KQL snippet (golden/snapshot style) for:
  • objectId = ""
  • allowedUsages = ["AutomatedFlows","ExternalTable","NativeIngestion"]
  • database = "MyDatabase"
• Ensure tests are deterministic and do not depend on external services.
• Keep changes small and readable; optimize for clear naming and minimal API surface.

Implementation steps (self-directed by agent):

1. Explore the repo to find how KustoSchemaTools currently generates the structured diff / output KQL/config.
2. Implement a new managed-identity policy generator module that outputs KQL text (and integrates with any existing structured response classes).
3. Extend the .NET options/input model to accept the new managed identity settings.
4. Add a unit test that asserts the produced KQL payload is correct.
5. Create a PR branch off main, commit changes, and open a PR targeting main.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: yes, please do option A. I will connect KustoSchemaTools as .net package

Assistant: Perfect. Next step is to inspect KustoSchemaTools’ current .NET API surface for “settings/config” and how it builds/runs KQL. Then we’ll add a new strongly-typed option for:

• objectId (string GUID)
• allowedUsages (string[])

…and have it generate the single KQL statement per database:

.alter-merge database <DB> policy managed_identity [
  { "ObjectId": "<OBJECT_ID>", "AllowedUsages": "AutomatedFlows,ExternalTable,NativeIngestion" }
]

Small plan (agree)

1. I’ll locate in github/KustoSchemaTools (your repo) the .NET project(s) and find where KQL “management commands” are built/executed.
2. I’ll find the current pattern for passing config/settings (e.g., options classes, JSON/YAML model, or method parameters).
3. I’ll propose the minimal new options class + wiring so your .net caller can pass objectId + allowedUsages.
4. Then we implement it in the smallest number of files, add tests (or a test harness) that validates the generated KQL string.

Before I touch the repo code: I need one thing from you so I don’t assume wrong APIs.

Clarifying question (must-have)

Which package do you consume from KustoSchemaTools?

• the name on NuGet (e.g. KustoSchemaTools.*), and
• the main entry type you call (a class name), if you know it.

If you don’t know those, just paste:

• the .csproj PackageReference line, and/or
• the minimal C# snippet where you currently trigger schema deployment / policy apply.

Once you paste that, I’ll:

• mirror the existing option style (Option A array),
• and keep the change localized + readable.

Якщо треба “інтересне слово”: «паралельність» — concurrency/parallelism, тобто робота з багатьма задачами одночасно (у нас зараз це не потрібно, але термін інколи важливий для пайплайнів деплою).

User: no, it would be the other way around. I will consume KustoSchemaTools in the other application.

Assistant: You’re right—your application will consume KustoSchemaTools (KustoSchemaTools provides a .NET API/package). ✅

Before we change anything, I need to find the actual repo code layout so we know where to add the new option and where KQL is executed.

Small plan (agree)

1. I’ll inspect github/KustoSchemaTools to find:
   • the main .NET projects/entrypoints
   • existing “policy/management KQL” support (if any)
   • the configuration/options pattern (likely strongly-typed options classes)
2. I’ll propose a minimal additive API:
   • ManagedIdentityPolicySettings { string ObjectId; string[] AllowedUsages; }
     ...